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System, Method and Computer Program Product for Authenticating Users 
Using a Lightweight Directory Access Protocol (LDAP) Directory Server 



Inventors: Thomas D. Ashoff 
Steve O, Chew 
Jeffirey J. Graham 
Andrew J. MuUican 

Background of the Invention 

Field of the Invention 

The present invention relates generally to user authentication mechanisms and more 
particularly to user authentication mechanisms for firewalls. 

Related Art 

Control over access to information technology (IT) resources is a common need today. A 
firewall can be used to protect IT resources behind the firewall Network firewalls can enforce a 
site's security policy by controlling the flow of traffic between two or more networks. For 
example J a company might encourage file transfers to the company's network that assist 
employees, but might discourage file transfers of potentially sensitive company confidential 
information firom the company network to external destinations. Firewalls often are placed 
between a corporate network and an external network such as, e.g., the Internet, or a partnering 
company's network. Firewalls can also be used to segment parts of a corporate network. A 
firewall system can provide both a perimeter defense to, e.g., an internal network, and a control 
point for monitoring access to and fi-om specific networks such as, e.g., an external network. 



31124 vl/RE 
_0K0I!.DOC 



1 



Firewalls can control access at a network level, an application level, or both. At the 
network level, a firewall can restrict packet flow based on protocol attributes. For example, the 
packet's source address, destination address, originating transmission control protocol / user 
datagram protocol (TCP/UDP) port, destination port, and protocol type can be used for the 
control decisions. At an appHcation level, a firewall can participate in communications between 
the source and destination applications with the firewall's control decisions being based on 
details of the conversation and other available information such as, e.g., previous connectivity or 
user identification. Thus, a firewall can authenticate users to control access to and firom IT 
resources behind and before the firewall. 

Firewalls can be packaged as system software, combined hardware and software, and, 
more recently, dedicated hardware appliances (e.g., embedded in routers, or easy-to-configure 
integrated hardware and software packages that can run on dedicated platforms). An example of 
an application-based firewall is the Gauntlet™ firewall available firom Network Associates, Inc. 

Firewalls can defend against attacks ranging from, e.g., unauthorized access, IP address 
"spoofing" (i.e., a technique by which hackers disguise traffic as coming from a trusted address 
to gain access to a protected network or resource), buffer overrun attacks, session hijacking, 
viruses and rogue applets, and rerouting of traffic. However, inherent limitations exist in certain 
services and protocols that conventional fu-ewalls cannot remedy. 

Conventionally, when software application programs sought to restrict what a user could 
do with the programs, the programs required identification of the user. For example, if a user 
desires access to sensitive corporate financial data in an accounting program, access to the data 
can be restiicted by means of authentication mechanisms such as, e.g., a password. The 
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application program therefore requires a list of users and identification information for the user 
for use in authenticating the user. 

Early software application programs often included their own integrated authentication 
mechanisms. Users often use a variety of software application programs, each possibly having its 
own authentication mechanism. Users find it cumbersome to remember different passwords 
associated with each of the multiple software application programs. 

IT resources used by companies today can include access to multiple software appUcation 
programs and Internet based applications. For example, employees at a given company can use 
e-mail and groupware applications, and other office automation programs including, e.g., 
spreadsheets, wordprocessors and presentation programs. As every application program 
conventionally has its own authentication mechanism, a separate database is initialized and 
updated for each application. 

Authentication mechanisms can use a query to a database known as a directory that can 
store information about users. A directory is similar to a database in that one can store 
information in a directory and later retrieve the information from it. However, a directory is 
specialized in that a directory is typically designed for reading more than writing, A directory 
offers a static view of the information and allows simple updates without transactions. Thus, 
while a database is typically written to and read from frequently, a directory by comparison is 
primarily read from and is infrequently updated. 

A directory service includes all the fiinctions of a directory and adds a network protocol 
that can be used to access the directory. Standardization is desirable in implementing a directory 
service. 
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An early standard for directory service was the directory access protocol (DAP), which 
originated in the European standards organization. DAP although specifying a vast, feature-rich 
protocol for storing and encoding directory information, was unwieldy in size. 

Today a new protocol, lightweight directory access protocol (LDAP), is gaining wide 
acceptance in business. The LDAP standard defines an information model for a directory, a 
namespace for defining how directory information is referenced and organized, and a network 
protocol for accessing information in the directory. LDAP can also include an application 
programming interface (API). The LDAP protocol mandates how client and server computers 
can communicate with the LDAP directory. However, LDAP does not mandate how data should 
be stored. LDAP directories are described in greater detail in "Introduction to Directories and the 
Lightweight Directory Access Protocol," available at http://w-w^\ stanfQrd.edu/-hodges/talks/ 
mactivitv.ldap.97/index2.html . More and more companies today use an LDAP directory server 
to store a database of employees. The LDAP directory generally can store an employee name, 
phone number, address and other information about the employee, and a password for modifying 
the employee's information. 

Firewalls also maintain a database of users and are operative to prompt users for an 
identifying user identifier and password. These conventional firewalls require that employee 
names and passwords be entered into a firewall authentication database. Maintenance of the 
firewall authentication database is especially burdensome where there are a large number of 
employees that are firequently leaving or joining a company or when a company has a large 
number of firewalls. Accordingly, what is needed is a mechanism for reducing this 
administrative burden. More specifically, what is needed is a mechanism for leveraging an 
existing LDAP directory server as part of a firewall's authentication process. In this manner, an 
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existing LDAP directory server can be used as a central directory that stores the data used by all 
applications. 

Summary of the Invention 

5 A system, method and computer program product for enabling the authentication of users 

to a firewall using a lightweight directory access protocol (LDAP) directory server is provided by 
the present invention. The firewall can be configured through a graphical user interface to 
implement an authentication scheme. The authentication scheme is based upon a determination 
of whether information contained in one or more LDAP entries satisfy an authorization filter. It 
is a feature of the present invention that the authentication scheme can be configured 
fj independently of specifically stated field requirements or schema of the firewall. In accordance 
u I with the present invention, the authentication scheme can be flexibly specified to interact with a 
- LDAP directory that has been uniquely developed for a company's internal needs. The 
\ \ company's investment in its existing administrative infirastructure can therefore be leveraged to a 
;45 greater degree. 

Brief Description of the Drawings 

The foregoing and other features and advantages of the invention will be apparent fi-om 
the following, more particular description of a preferred embodiment of the invention, as 
20 illustrated in the accompanying drawings. 

FIG. 1 illustrates a communications network including a firewall. 

FIG. 2 illustrates a communications network including a lightweight directory access 
protocol (LDAP) directory server and an authorization module within a firewall. 
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FIG. 3 illustrates the authentication of a client user through a firewall. 
FIG. 4 illustrates an example embodiment of an LDAP directory tree. 
FIG. 5 illustrates an embodiment of a graphical user interface for configuring the LDAP 
authentication feature. 

Detailed Description of the Invention 

A preferred embodiment of the invention is discussed in detail below. While specific 
implementations are discussed, it should be understood that this is done for illustration purposes 
only. A person skilled in the relevant art will recognize that other components and 
configurations may be used without parting firom the spirit and scope of the invention. 

FIG. 1 illustrates an example embodiment of a communications network 100 including 
client computers 102a and 102b coupled via an internal network 104 to an internal server 
computer 106 and a firewall 1 10. Communications network 100 also includes a client computer 
102c coupled via an internal network 1 12 to firewall 110. Finally, communications network 100 
includes client computers 1 16a and 1 16b coupled via an external network 1 14 to an external 
server computer 1 1 8 and firewall 1 1 0. External network 1 14 can represent, e.g., the Global 
Internet, or a partnering company's network. 

Network firewall 1 1 0 can enforce a business' security policy by controlling the flow of 
traffic between two or more networks such as, e.g., internal networks 104 and 1 12 and extemal 
network 114. In general, firewall 110 serves to isolate internal networks 104 and 1 12 fi-om one 
another and also fi-om extemal network 1 14, 

As illustrated in FIG. 1, firewall 1 10 can be used to segment parts of a corporate network. 
For example, firewall 1 10 can be used to control information flow between a corporation's 
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internal networks 104, 1 12. Firewall 1 10 can also provide a perimeter defense between an 
internal network 104, 1 12 and an external network 1 14. 

FIG. 2 illustrates an example embodiment of a communications network 200 that 
includes client computer 102a coupled via internal network 104 to internal server 106 and to 
firewall 210. Firewall 210 is also coupled via external network 1 14 to extemal server 118. 

As shown, client computer 102a includes a browser 202. Browser 202 can in one 
embodiment be an Internet browser that provides a graphical user interface to network resources. 
Browser 202 is generally operative to parse and make requests to network resources such as, e.g., 
extemal server 118, and present the results of the request to a client user viewing cHent computer 
102a. 

Intemal server 106 is shown including a lightweight directory access protocol (LDAP) 
directory 204, which can be configured to store employee information. For example, a human 
resources database could be stored as an LDAP directory having a directory structure such as that 
illustrated in FIG. 4. As illustrated, LDAP directory tree 400 includes country 402 set in this 
example to US, organization 404 set to NAI, location 406 set to Rockville and location 408 set to 
Santa Clara, department 410 set to engineering and department 412 set to sales, and usemame 
414 set to amuUican and usemame 416 set to jgraham, 

Extemal server 1 1 8 can include an Internet server application. In one embodiment, the 
Intemet server application supports file transfer protocol (FTP) communication. As would be 
apparent to those skilled in the relevant art, other types of server appUcations can be included on 
extemal server 118 including, e.g., databases, and electronic mail. 

Firewall 210 is shown including an authorization module 206. Authorization module 206 
is used to authenticate a client user (e.g., client computer 102a) to determine if the client user's 
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communication is authorized to pass through firewall 210. Conventional firewalls 1 10 included 
their own database having a Hst of users and passwords, to enable authentication through firewall 
110. 

In accordance with the present invention, firewall 210 does not authenticate users using 
5 its own database. Rather, firewall 210 authenticates users using information contained within 
LDAP directory 204. As will be described in greater detail below, firewall 210 can authenticate 
users through an authentication scheme that can be based upon the unique composition of an 
organization's LDAP directory 204. 

It is a feature of the present invention that the authentication scheme of the present 
4 invention can operate independently of specifically stated field requirements or schema of the 
i'S firewall 210. In other words, an organization's LDAP directory 204 need not be modified to 
L n conform to a schema imposed by the firewall 2 1 0, Moreover, resistance to such a modification 
i= will not result in the maintenance of multiple directories. 

^ ^ In accordance with the present invention, the authentication scheme can be flexibly 

t h specified to interact with an existing LDAP directory that has been uniquely developed for a 
'^'^ organization's internal needs. This fi-amework enables a firewall administrator to seamlessly 
integrate a firewall product into an existing administrative infi-astructure. The organization's 
investment in the existing administrative infi*astructure can therefore be leveraged to a greater 
degree. 

20 FIG. 3 illustrates the authentication process that is implemented by firewall 210. In the 

illustrated example, firewall 210 authenticates a client user at client computer 102a running a 
browser 202 that is attempting to access an application or resource on external server 118. This 
access path is illustrated by path 302. 
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This authentication process begins when client computer 102a initiates a network 
resource request 304 from browser 202. The network resource request 304 is intercepted by 
firewall 210. Authorization module 206 within firewall 210 challenges the cKent user to identify 
himself or herself. A challenge could in one embodiment include a request for entry of a 
usemame and password. Upon receipt of the identification information, authorization module 
206 searches an authentication database (not shown) to identify an authentication method (e.g., 
LDAP authentication). If no entry in the authentication database is found for the client user, then 
a default authentication method can be used. In the LDAP authentication process, authorization 
module 206 binds to LDAP directory 204 and uses the userPassword attribute for authentication. 

After authorization module 206 authenticates the client user, authorization module 206 
then determines whether the client user is authorized to have his access request fulfilled. The 
LDAP authorization process is illustrated as communications 306 and 308. Communications 306 
and 308 are facilitated using the LDAP protocol and may utilize the secure sockets layer. 

If per-user authorization is configured, authorization module 206 determines whether one 
or more attributes of the client user's LDAP entry satisfies an authorization filter. If the one or 
more attributes of the client user's LDAP entry does not satisfy the authorization filter, then 
authorization module 206 determines that the authorization fails. If the authorization filter is 
satisfied, then the client user's network resource request is allowed through firewall 210. This 
allowed connection is illustrated in FIG. 3 as path 310. 

To support per-user authorization, an administrator configures an authorization filter to 
use when authenticating users. One or more attributes in the client user's LDAP directory entry 
and associated values can be selected for the authorization filter. Once configured, authorization 
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module 206 can verify that the LDAP entry used in the bind call satisfies the authorization filter 
before allowing the user access to/through the firewall 

FIG. 5 illustrates an example embodiment of a graphical user interface (GUI) 500 of a 
firewall systems administrator application screen. As shown by a selected radio button, LDAP 
authentication 502 has been selected. GUI 500 includes a primary LDAP server settings area 
5] 0, a secondary LDAP server settings area 520, an authentication settings area 530, and a per- 
user authorization settings area 540. 

The primary LDAP server settings area 510 includes a host field 512 and a port field 514. 
The host field 5 12 can be used to enter an IP address or host name of a primary LDAP server. 
The port field 5 14 can be used to enter the port to be used on the primary LDAP server. 

The secondary LDAP server settings area 520 also includes a host field 522 and a port 
field 524. The host field 522 can be used to enter an IP address or host name of a secondary 
LDAP server. The port field 524 is used to enter the port to be used on the secondary LDAP 
server. Fields 522, 524 can be left blank if no secondary LDAP server is being used. 

The authentication settings area 530, can include searchbase field 532 and a usemame 
attribute field 534. The searchbase field 532 can be used to indicate the top of the directory tree 
400 such as, e.g., country 402, organization 404, location 406, and department 410, so that a 
lookup can be within that portion of the directory tree. For example, a set of attribute pairs such 
as, e.g., o=NAI, c=US to append to all requests to the LDAP server can be entered. The 
usemame attribute field 534 can include a default usemame attribute such as, e.g., uid. The 
usemame attribute field 534 can be used in performing per-user authorization. 

The per-user authorization settings area 540 includes a search filter field 542 and a 
timeout field 544. The timeout field 544 can include a default value such as, e.g., 60 seconds. 
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For example, timeout field 544 can be used to limit the amount of time the authorization filter 
query can take. If the time is exceeded, the authorization fails. 

The search filter field 542 is used by firewall 210 in identifying the appropriate fields that 
are the subject of the LDAP directory authentication query. Upon receipt of a response from the 
5 LDAP directory 204, firewall 210 can then determine whether the cHent user is authorized to 
authenticate through the firewall 210. 

In general, the authorization filter can contam any LDAP-valid combination of attributes 
and values, including object classes. At its simplest, the authorization filter specifies a single 
attribute and value pair. For example, the search filter field 542 can be used to enter a search 
% filter expression such as "objectclass^gauntietUser." 

I i Consider another example where LDAP directory 204 is configured by the company to 

in inchide a field that would provide an access code level for each user. For example a "1" could 
correspond to only e-mail access, while a 5 could mean full access to all Internet services 
including worid wide web browsing. In this environment, an authorization filter can be specified 

1 as "(&(objectclass=gUser)(status>=5))". 

It should be noted that the authorization process need not be based on per-user 
authorization. In another embodiment, the authorization process can be based on a per-service 
authorization. In this embodiment, the per-service authorization can include an authorization for 
protocol services. Examples of protocol services include FTP, simple mail transport protocol 

20 (SMTP) e-mail, hypertext transport protocol (HTTP), etc. The per-service authorization can also 
be based on LDAP directory information. For example, authorization module 206 can use group 
memberships to determine whether a client user can use HTTP through firewall 210. To satisfy 
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this authorization process, the authenticated user must be a member of the "web-users" group in 
the LDAP directory. 

In one embodiment, the per-service authorization process uses the standard 
groupOfNames and groupOfUniqueNames object classes for authorization decisions. In general, 
a mechanism can be included that supports the specification of arbitrary group names for each 
service to be controlled. Control can then be based on a per-proxy basis or a per-policy basis. 

Specification of per-service authorization criteria can also be implemented using the 
search filter field 542. In general, a different search (or authorization) filter can be provided for 
each service. For example, a search filter field caa be included in GUI 500 to determine vv^hether, 
e.g., a user is authorized to perform a file transfer, to send e-mail, or to access the world wide 
web. A search fiher field can also be included in GUI 500 to determine whether, e.g., a user is a 
member of a particular group such as, e.g., engineering department 410, and if so, then particular 
services can be authorized based on being part of that group. 

As noted, it is a feature of the present invention that firewall 210 caB support arbitrary 
LDAP directory schema. Accordingly, firewall 210 does not require additional firewall-specific 
object classes or attributes in the directory. Customers can populate the LDAP directories with 
whatever data they require. This authentication environment can be flexibly applied across 
multiple organizations each having their own sets of directory information. Indeed, the concepts 
of the present invention can be used to implement an authorization filter that relies on portions of 
information that are stored in distinct LDAP directories. This distributed authentication scheme 
enables an organization to implement segmented management of the user database. 

While various embodiments of the present invention have been described above, it should 
be understood that they have been presented by way of example only, and not limitation. Thus, 
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the breadth and scope of the present invention should not be limited by any of the above- 
described exemplary embodiments, but should be defined only in accordance with the following 
claims and their equivalents. 



31124vl/RE 
OKOU.DOC 



13 



What is Claimed is: 

1 . A system for authorizing client access to a network resource, comprising: 

at least one directory that can be accessed using a network protocol, said at least one 
directory being configured to store information concerning an entity's organization; and 

a firewall that is configured to intercept network resource requests fi-om a plurality of 
client users, said firewall being operative to authorize a network resource request based upon a 
comparison of the contents of at least part of one or more entries in said at least one directory to 
an authorization filter, wherein said authorization filter is generated based on a directory schema 
that is predefined by said entity. 

2. The system of claim 1 , wherein said at least one directory is a lightweight 
directory access protocol directory. 

3. The system of claim 1, wherein said authorization filter is specified using a 
graphical user interface, 

4. The system of claim 1, wherein said authorization filter implements a per-user 
authentication scheme. 

5. The system of claim 1 , wherein said authorization filter implements a per-service 
authentication scheme. 
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6. The system of claim 1 , wherein said firewall and said directory communicate 
using secure socket layer communication. 



7. The system of claim 1 , wherein said firewall is configured to query multiple 
directories. 



8. An authentication method at a firewall, comprising the steps of: 

(a) receiving a network resource request firom a client user; 

(b) querying, using a network protocol, at least one directory that is configured to 
store information concerning an entity's organization, wherein said query is based upon an 
authorization filter that is generated based on a directory schema that is predefined by said entity; 

(c) determining, based on the results of said query, whether the contents of at least 
part of one or more entries in said at least one directory satisfy said autiiorization filter; and 

(d) permitting said network resource request through said firewall if said 
authorization filter is satisfied. 

9. The method of claim 8, wherein step (b) comprises the step of querying said at 
least one directory using a lightweight directory access protocol. 

10. The method of claim 8, further comprising the step of specifying an authorization 
filter using a graphical user interface. 
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11. The method of claim 1 0, wherein said specifying step comprises the step of 
specifying an authorization filter that implements a per-user authentication scheme. 

12. The method of claim 1 0, wherein said specifying step comprises the step of 
specifying an authorization filter that implements a per-service authentication scheme. 

13. The method of claim 8, wherein step (b) comprises the step of querying said 
directory using secure socket layer communication. 

14. The method of claim 8, wherein step (b) comprises the step of querying multiple 
directories. 

15. The method of claim 8, wherein step (a) comprises the step of receiving a network 
resource request firom a client user at an internal network. 

16. The method of claim 8, wherein step (a) comprises the step of receiving a network 
resource request fi-om a client user at an external network. 

17. A computer program product for enabhng a processor in a computer system to 
implement an authentication process, said computer program product comprising: 

a computer usable medium having computer readable program code embodied in said 
medium for causing a program to execute on the computer system, said computer readable 
program code comprising: 
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first computer readable program code for enabling the computer system to receive a 
network resource request fi*om a client user; 

second computer readable program code for enabling the computer system to query, using 
a network protocol, at least one directory that is configured to store information concerning an 
entity's organization, wherein said query is based upon an authorization filter that is generated 
based on a directory schema that is predefined by said entity; 

third computer readable program code for enabUng the computer system to determine, 
based on the results of said query, whether the contents of at least part of one or more entries in 
said at least one directory satisfy said authorization filter; and 

fourth computer readable program code for enabling the computer system to permit said 
network resource request through said firewall if said authorization filter is satisfied. 
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Abstract 

A system, method and computer program product for providing authentication to a 
firewall using a lightweight directory access protocol (LDAP) directory server is disclosed. The 
firewall can be configured through a graphical user interface to implement an authentication 
scheme. The authentication scheme is based upon a determination of whether at least part of one 
or more LDAP entries satisfy an authorization filter. 
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